Add admin-editable alternative search terms per mod, searchable on /admin/ranked-mods - #52

pinBranchVersionIfNew() (previous commit) only pins a version's downloadUrl
the first time it's synced -- every mod_registry_versions row written
before that fix exists is still sitting on its original moving-branch-tip
URL, with a sha256 computed against whatever that tip happened to be at
hash-time (not necessarily the exact commit its own version label names).

Add backfill-branch-pins.ts (pnpm backfill-branch-pins), a one-off script
in the same shape as the existing backfill-mod-hashes.ts: finds every
mod_registry_versions row whose downloadUrl still classifies as 'branch',
resolves a commit-pinned URL for it, and *re-downloads and re-hashes* it
against that pinned URL rather than trusting the existing stored hash --
the old hash could already be wrong for the commit it's about to be
pinned to, so only a fresh hash guarantees correctness.

Each row gets up to 3 resolve+hash attempts with a short backoff before
being marked via a new mod_registry_versions.pin_failed_at column
(migration 0036) and skipped on future runs -- so a genuinely dead
repo/branch/commit doesn't keep burning GitHub API calls on every
re-run. Pass --retry-failed to re-attempt previously-marked rows (e.g.
after a renamed repo or an expired rate limit).

New gateway functions in mods.gateway.ts: listVersionsWithDownloadUrl
(broad fetch, filtered/classified in TS same as listAllVersionsWithDownloadUrl),
applyBranchPin (writes the pinned URL + hash, clears pinFailedAt),
markVersionPinFailed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…dmin/ranked-mods

Admins managing the ranked mod catalog had no way to find a mod by
anything other than its real title/id - e.g. "What's in my Fool" is
commonly called "wimf" by players, but typing that into a (previously
nonexistent) search box would have found nothing.

- mod_registry gets a new search_terms text[] column (migration
  0036_mod_search_terms.sql), same shape as the existing categories
  column but with no upstream-index counterpart at all: unlike
  categories/title/author/etc (SYNCABLE_MOD_FIELDS), this is never
  touched by the hourly upstream sync and never participates in
  overriddenFields - there's no upstream value for it to ever protect.
  updateModFields() writes it directly instead of through the
  touch()/overriddenFields path the ten real syncable fields use.
- Editable via the same admin field-edit form as categories (PATCH
  /webadmin/mods/:modId, and at creation via POST /webadmin/mods /
  PUT .../custom) - a comma-separated "Alternative search terms" input
  right below Categories in the mod dialog.
- /admin/ranked-mods now has an actual search box (there wasn't one at
  all before) that filters the already-loaded catalog client-side by
  name, id, or any searchTerms entry, case-insensitive substring on
  each - the catalog is small enough this needs no server round trip
  per keystroke. The table's empty-state message now distinguishes "no
  mods synced yet" from "no mods match this search".

Verified: tsc --noEmit on both apps/server and apps/web shows no errors
introduced by this change (every remaining error is a pre-existing
missing-module gap in this checkout, e.g. @bmp/types/sanitize-html not
installed, unrelated to any file this touches). biome check flagged
only pre-existing formatting/line-ending debt already present on these
files before this change (confirmed via git stash comparison), nothing
new.

Not yet run against a live database - the migration should be applied
(pnpm migrate) before this deploys.